了解拳头玩家平台团队如何在Xbox Game Pass上发行游戏

为了提供最佳用户体验，我们希望玩家连接他们的活跃Xbox Game Pass账号后，能够立刻解锁新的游戏内容，这需要动很多脑筋。内容体验团队与账号团队（玩家平台内部）合作，实现了玩家每次绑定或解绑他们的Xbox账号时，都由账号发送一条信息到Riot Event Bus（拳头最新的基于信息的沟通方式）。收到信息后，监控消息代理主体的服务就能进行响应，处理该事件了。由于玩家可能在没有激活Game Pass的情况下去连接他们的Xbox账号，因此团队也需要询问Xbox API，使用账号连接提供的令牌获取该信息，由账号团队将令牌存在新的服务中。但这样也只能解决一部分问题，我们还是需要查看玩家是否有活跃的Xbox Game Pass账号。

内容体验团队（玩家平台的一部分）搭建了一套门户订阅服务（GSS），作为拳头内部唯一的玩家Game Pass状态信息来源，处理所有相关的调用。也就是说每当有服务需要查看任何基于订阅的内容时，都可以调用GSS，获得关于玩家所享受服务的低延迟、高可靠性响应。GSS获取数据的方式，是消耗账号提供的账号连接事件，并使用微软API查看玩家的Game Pass激活状态。它通过HTTP API端点向其他拳头服务提供该数据，让其他团队将该信息用于不同的用例，包括：

内容获取平台：为玩家的藏品添加基于订阅的特定内容

市场技术：根据玩家当前Game Pass状态，显示特定广告

玩家支持：玩家支持代理利用该信息处理Xbox订阅相关玩家工单

网页体验：在玩家账号管理网页上显示玩家的订阅状态

当玩家将拳头账号与Xbox Game Pass账号连接时，GSS将调用微软Xbox API，用账号连接令牌获取玩家的Game Pass状态，将该信息保存在永久数据库中，定期更新，并通过API供客户端访问调用。是不是很简单？ 

玩家连接拳头 + Xbox账号后，可以随时激活他们的Game Pass。该服务只支持定期调用Xbox API，查看玩家的激活状态。为了提供最好的玩家体验，我们希望玩家连接并激活Game Pass后，立刻就能访问订阅内容，所以必须能频繁调用。但到底需要达到多高的频率呢？每分钟一次当然最好，但为了查看状态，每分钟向一个API发起数百万次请求，而且99%的情况下两次调用之间并没有什么变化，这并不是理想的实践。

团队关注能够在拳头一侧响应玩家互动的实例，比如玩家启动游戏客户端时，就是刷新Game Pass状态的理想时机。但是刷新是一项外部HTTP调用，需要大约一秒时间，而主GSS客户端、内容获取平台（CAP），需要在50毫秒内获得响应，因为这是获取玩家藏品的时间关键路径的一部分。耗时一秒的外部调用不能满足50毫秒的要求，所以团队必须发挥创造力。他们决定先返回当前存储的值（上一次刷新时获取或是账号连接时获得的原始值），同时如果该数值是在两分钟或更久之前获取的，则在后端触发一次异步刷新。异步刷新后，如果服务器发现Game Pass状态变化，会通过拳头信息服务向游戏客户端发送一条信息，让游戏从CAP获取授权信息，确保玩家不用重新手动加载客户端，就能获得他们的订阅内容。 

“我们的主要目标是尽可能降低延迟，满足严格的时间要求。CAP呼叫我们，获得玩家的Game Pass激活状态，基本需要保持在50毫秒内，从而让我们达到接近实时服务的效果。如果不能在该时限内响应，CAP会立刻判断呼叫超时，有可能导致玩家无法获得本应拿到的内容。”

- Vasily Katraev 

《英雄联盟手游》的玩家藏品没有使用CAP系统，因此需要直接询问订阅服务，了解玩家是否有激活的Game Pass订阅。为了满足50毫秒的延迟要求，内容体验将他们的服务与CAP和账号管理服务设置在了一起，分布在全球四处数据中心内，以便尽可能靠近我们的玩家。  

在与玩家见面几天前，团队会进行灰度发布，测试拳头账号和Xbox Game Pass之间的连接。在发布日之前，他们发现了多个关键漏洞，并及时修复。

授权服务的用户负载量是一个主要隐患。该服务负责所有拳头游戏内的玩家物品访问授权。授权会收到许多读取请求，在有些地方甚至会达到一分钟八十万次！为了解锁玩家的福利，每次授权调用都会触发其他系统的后续调用，查看玩家是否拥有Game Pass，然后组装并返回玩家的Game Pass福利。这套流程带来的额外压力和复杂度会带来可靠性风险，并拖慢多种后续的下游响应速度。

团队进行了多种场景的负载测试，发现只有通过灰度发布，他们对系统的稳健度才最有信心。灰度发布能够让他们完整地“开启系统”，只不过少了最后一步，也就是玩家不会真的看到Xbox Game Pass的内容。在正式发布前，他们看到了系统会承受的全部压力，以及具体的行为情况。通过灰度发布，他们发现有一个连接池配置错误，可能导致启动失败，玩家无法获取福利。

团队还遇到了数据库写入承载量的问题，现有架构无法进行扩展*，以支持合作发布期间的玩家量增加。在管理此类服务的负载时，一个常用的方式是分批访问。团队尝试通过将市场服务分为几次进行，控制玩家流量。这样可以在长期分散玩家批次，让团队确保随着更多市场材料上线，他们具有足够的服务能力应对每批新玩家。通过与市场团队密切配合，他们将流量一直保持在了写入承载量的50%以下。 

* 此后我们调整了数据库技术堆栈，使其具有更大的账号调整水平扩展能力。